Q: I built an MPW tool that waits until a certain file exists and then deletes it. To be MultiFinder friendly, this tool makes calls to SpinCursor to free up the processor, but it seems to be using an excessive amount of processor time. I tried putting a call to WaitNextEvent in the tool and using a large sleep value, but this crashed MPW.

Is there a way in an MPW tool to release the processor and go to sleep for a specified interval, or am I stuck with hogging the processor via SpinCursor?

A: Because MPW tools run in the MPW Shell, the only MPW code that gets processor time within the MPW environment is the executing tool. Other applications running on the machine get processor time only when the front application, the MPW Shell, explicitly yields by calling WaitNextEvent or something similar. This is a potential problem, because MPW tools running within the application won't do this, so other applications won't get a chance at the processor. The RotateCursor and SpinCursor calls address this problem by processing mouseDown events. However, this has nothing to do with something else running within the MPW Shell. The MPW Shell would have to start each tool in a separate thread for the MPW tools to run in the background (see references).

Unfortunately, there is no way to change the sleep value passed to WaitNextEvent from the MPW Shell when executing a tool, but you could move the section of code that checks for and deletes the file from the MPW tool into a Background Only Application (BOA). (These are sometimes called Faceless Background Applications, or FBAs). This would let you run it continuously, and you won't even notice it, and you would have more control over the process. If you need access to some MPW Shell variables, your tool can get the data, package it in an AppleEvent, and send it to the BOA. You could have the tool launch the BOA, but if you set the BOA file type to 'appe', it can be installed in the Extensions folder so it will be launched at startup.

Note that if MPW could use a larger sleep value, it would be in danger of being unable to respond to user requests in a timely manner, and as a result, the cursor might not get set to an arrow when the user drags it over another application's window.

The sample tool below does what you want and works as expected. While MPW is in the foreground, the tool does its processing, and applications running in the background get an acceptable amount of background time and receive null events, depending on their own sleeptime setting. A sample application that was modified to check when null events are received in the background receives sufficient null events to do background processing while the MPW Shell is in the foreground and is running the tool.

Compare the sample tool's source code with yours, and try it to see if it works for you under similar conditions. If you want the MPW Shell to provide a very large amount of time to background applications while your tool is executing (rather than just receiving time to perform periodic actions), this approach won't work, and you'll have to resort to the BOA approach.

main(int argc, char *argv[])
{
   long status;
   status = 0;
   InitCursorCtl ( nil );

   while ( -1 )/* drop out on a cmd-. */
   {
   do_something ( );
   SpinCursor ( 1 );
   }

   return status;
}

void do_something ( void )
{
   FSSpec theSpec;
   if ( !(FSMakeFSSpec ( 0, 0, 
        "\pMacintosh HD:Delete Contents:SoonToBeNoMore", &theSpec )) )
   FSpDelete ( &theSpec );
}

References:

Building and Managing Programs in MPW, 9-4, "Conventions for the Behavior of MPW Tools"

IM - Processes, 1-5, "About Processes"

IM - Interapplication Communication

Technote 1070 - Background-Only Applications

Developer CD: ToolChest Edition: InterApplication Communication

Developer Documentation | Technical Notes | Development Kits | Sample Code